1. Field of the Invention
The present invention generally relates to a physically secure forgery-resistant authorization device in the form of a token or key card. The token or key card represents authorization to perform some action or transaction such as providing access to information or a physical place. More particularly, this invention relates to a write-once-read-once batteryless authentication token having particular application in hardware-based security systems.
2. Description of the Prior Art
A security system is described in an article by Steve R. White and Liam Comerford entitled "ABYSS A Trusted Architecture for Software Protection", pp. 38-51, Proceedings of the IEEE Computer Society Conference on Security and Privacy, Oakland, Calif., Apr. 27-29, 1987. In that system, a use-once authentication mechanism, called a token, solves the problem of providing authorization to a computer to execute a piece of protected software without requiring the user to have two way communication with the software source. The system has many security applications, but in particular, enforcement of terms and conditions of the sale of software is mentioned.
The token is a small hardware device which may be characterized as analogous to a theater ticket. It is examined in an electronic transaction to ascertain whether or not it is valid and is concomitantly invalidated. The fact that invalidation is inherent in the examination process makes it a read-once device. The way that the token is examined to prove validity is straightforward. The token contains two forms of data. One form of the data is read and compared with what the token is expected to contain. If it matches, the token is valid. Note that the other form of the data in the token is an encrypted copy of the first form. The examining hardware has a cryptographic key to decode the second form of data for purposes of making the comparison with the first form of the data.
What makes the token a unique and viable authentication agent is that its architecture effectively prevents its forgery. That is, even if a query which requests data from the token and the token response are recorded, this information is not useful in an attempt to correctly answer a second query.
The token examination process consists of a random series of one-bit queries to the token and responses from the token during which a subset of the token's data is requested and revealed. For each bit of data which is revealed, a bit of data is destroyed. By the end of this process, half of the data contained in the token has been revealed and half has been destroyed, rendering it useless for further operations. To simulate this action, i.e., forge a token, one must be prepared to respond correctly to any sequence of queries. This implies that one must know the entire token contents. In general, at most half of any token's data is examined. This amount is sufficient to establish that the token is valid, but not enough to afford a prospective forger the information required to simulate a valid token in the face of any sequence of queries which differ in any way from the first examination.
FIG. 1 shows the logical and physical connection of a token 12 to a validating processor 10. To test for a valid token, the validating processor generates a random bit sequence, or query. It places the first bit on the token's query line 14 and pulses the token's clock line 16. The token places the content of the selected register on its output line 18. The processor 10 reads this value, stores it, and repeats the process with the next bit of the query. After completing the query/response sequence, the processor compares the response sequence with the expected response sequence to the given query. This expected response sequence is found by simulating the token query process using data supplied to the validating processor by other, typically cryptographic, channels. If they match, the token is considered valid.
FIGS. 2A and 2B illustrate both the simplified token architecture and a sample portion of the token validation sequence. The token's data is stored in two n-bit shift registers 20 and 22. These shift registers feed into a multiplexer 23 which routes the data in response to the query line 24 from the selected register to the response line 28. Upon each register shift, each register shifts out one bit of data and shifts in a zero. This effectively erases the token after n-queries and renders the token useless. In the sample sequence shown, the procedure begins with "what's currently in the UP register?", and the response returned is "zero". The data in the DOWN register 22 is also shifted out, as indicated in FIG. 2B, but it is not provided to any external terminal of the device. This procedure is repeated n times with n randomly selected queries, during which n bits of data are revealed and n bits discarded.
In the current ABYSS security system, the tokens which allow access to the system are operated under battery power which gives the tokens a limited life and added cost of manufacture.